Technical Field
The present disclosure generally relates to secure communications between a remote network computing server and a mobile device. More particularly, but not exclusively, the present disclosure relates to a security module having a plurality of unassigned secure domains, each of the unassigned secure domains later assignable to a client.
Description of the Related Art
Generally speaking, remote servers host software applications that interact with other software applications executing on mobile communication devices such as smartphones. Service providers perform a key exchange ceremony with a security module issuer. One or more key diversification functions are then performed to derive other secret keys, which are used to encrypt secret information that will be communicated between the remote server and the mobile device. The encrypted information is passed from the remote server to the mobile network operator (MNO), and the MNO passes the data to the mobile device. In the mobile device, the subscriber identity module (SIM) is needed to decode each packet of secret information. Alternatively, the mobile device encrypts information using secret key data stored in the SIM and passes the encrypted information to the MNO, which forwards it to the remote server.
FIG. 1 illustrates conventional provisioning and security-card-based communication of secure data through a mobile network 10a. In FIG. 1, a secure communications infrastructure includes a mobile device 12 such as a smartphone associated with (e.g., having embedded or placed therein) a security module 14 such as a SIM card. The mobile device has a direct communicative relationship 16 with the security module 14. The communications may occur via a single wire protocol (SWP) bus, an I2C bus, serial peripheral interface (SPI) bus, or some other communication path and protocol.
The mobile device 12 in FIG. 1 is illustrated as a smartphone, but other devices are contemplated. For example, mobile device 12 may be embodied as a tablet computing device, a laptop computer, a multimedia device, exercise equipment, or in some other form. The mobile device 12 may be any computing device that is arranged to wirelessly communicate 18 over a wide area wireless network such as a cellular network that conforms to a 3G, 4G GSM protocol, long term evolution (LTE) protocol, a 5G protocol, or some other wireless communication network protocol. Typically, the wide area wireless network is administered by a network service provider 20, which is also called a mobile network operator (MNO).
The mobile device 12 communicates with the MNO 20 that provides the wireless mobile network services. The MNO 20 is closely aligned with data in the security module 14 and, most often, the MNO 20 provisions the initial data into the security module 14. Generally speaking, in communication sessions (e.g., phone calls, electronic mail, text messages, and the like) where the mobile device accesses services provided by the MNO 20, information from the security module 14 is passed to the MNO 20.
A secure element issuer-trusted service manager (SEI-TSM) 22 provides cryptographic tools and data 24 such as public and private keys and encryption/decryption algorithms to the MNO 20 and other entities, some of which are associated with the MNO 20. The SEI-TSM 22 could be the MNO 20, a silicon maker such as STMICROELECTRONICS, an original equipment manufacturer (OEM) that manufactures mobile devices, or some other entity. One valuable function performed by the SEI-TSM 22 is to establish a secure hypertext transfer protocol (HTTPS) link to the security module.
When a new set of relationships for a new service provider are being provisioned, the SEI-TSM 22 creates a new service provider secure domain (SPSD) in the security module. Security keys exchanged during a key ceremony are programmed for use in the secure domain and for further access by the service provider's trusted service manager. In some cases, the SEI-TSM 22 may also extradite the SPSD, which means the SEI-TSM may delete or otherwise give up its ability to read or write any data into the SPSD. After an SPSD of a security module 14 is extradited, the SEI-TSM 22 will pass secure (i.e., encrypted or otherwise obfuscated) packets to the security module originated from SP-TSM or otherwise, but the SEI-TSM 22 will not have any ability to view or otherwise interpret the data packets being passed.
A second trusted service manager coupled with a service provider (SP-TSM) 26 is separated from the SEI-TSM 22 by an optional interoperability facilitator 28. The interoperability facilitator 28 permits the sharing of disparate data structures, protocols, and the like between trusted service managers and other computing devices. The SP-TSM 26 is coupled through a same or different interoperability facilitator 28 to one or more service providers 32.
The SP-TSM 26 exchanges secure information with SEI-TSM 22. Keys from the SP-TSM can be programmed into an SPSD of the security module 14, and other keys associated with the SPSD are passed to the service provider 32. Broadly speaking, the SP-TSM 26 encrypts data with the keys that correspond to the SPSD, and it interprets data from the service provider. The SP-TSM 26 also formats the data from the service provider into application protocol data units (APDUs) that are recognized by the security module and unfolded by an application executing on the mobile device.
Service providers 32 conventionally include large national and international banking service providers such as the BANK OF AMERICA, and CITIGROUP, payment service providers such as VISA and MASTERCARD, large retailers such as APPLE, TARGET, and STARBUCKS, and others.
The system described in FIG. 1 is very complex and very expensive. In order to implement such a system, service providers 32 are required to acquire their own trusted service manager or pay for very expensive, customized access to a trusted service manager. That is, the SP-TSM 26 of FIG. 1 is necessary for a service provider to offer mobile payment to their customers, and so the service provider must set up their own SP-TSM 26, which is very expensive, or the service provider must contract for specific access to an SP-TSM 26, which is also very expensive.
The SP-TSM 26 forms a secure communicative relationship with the secure element issuer-trusted service manager (SEI-TSM) 22. Looking broadly at FIG. 1, the SP-TSM 26 forms a secure relationship with a particular service provider 32; and the SEI-TSM 22 forms a secure relationship through a network controlled by an MNO 20 with a security module 14. In this way, the service provider 32 is able to securely exchange secret information with the security module 14 over a particular customer. The security in the communicative relationship is enabled via the communication between the two trusted service managers, SP-TSM 26 and SEI-TSM 22. Accordingly, once the security module 14 is in use by a customer, new services can only be deployed through the connection between SP-TSM 26 and SEI-TSM 22.
Looking more closely, the process to pass secure data between the service provider 32 and the security module 14 becomes very complex. The relationship between the service provider and its associated SP-TSM 26 requires a particular security mechanism maintained and passed between the devices, and the relationship between the SEI-TSM 22 and the security module 14 also requires particular security keys maintained and passed between these devices. The trusted service managers pass encrypted data based on rotated keys, and the complexity to maintain secure and valid keys is performed through key exchange ceremonies, key diversification procedures, and key rotation techniques. With multiple applications on each device, and hundreds, thousands, and even millions of devices, the conventional process requires accurate timing, voluminous computing resources, a large communication bandwidth, and substantial power, among other things. This infrastructure is necessary because a generic HTTPS server such as implemented by a service provider 32 cannot securely talk to a security module 14 on the mobile device, even when the security module includes a bearer independent protocol (BIP) interface. Stated differently, even though secure services may be stored and executed in the conventional security module, the conventional security module is only enabled for secure communications with a trusted service manager.
Two conventional models of the conventional provisioning and security-card-based communications systems are currently in use.
FIG. 2A illustrates the conventional provisioning and security-card-based communication of FIG. 1 in a multiple service provider trusted service manager approach 10b. In FIG. 2A, three service providers are illustrated: a banking service provider 32a, a government service provider 32b, and a retail service provider 32c, and each of the service providers has a dedicated SP-TSM 26a-26c. In this delegated management approach, all of the SP-TSMs communicate through a central SEI-TSM 22a to a security module 14a associated with a mobile device 12a communicating on a wireless network operated by a particular mobile network operator (MNO) 20a. Implementation and maintenance of this architecture is very expensive for each of the service providers 32a-32c because each of the service providers 32a-32c must set up an SP-TSM 26a-26c expressly configured for secure communications through the SEI-TSM 22a, which is typically controlled by an MNO or a security card OEM. Often, this approach cannot be justified for smaller banks, utility service providers, retail establishments, and others.
FIG. 2B illustrates the conventional provisioning and security-card-based communication of FIG. 1 in a single service provider trusted service manager approach 10c. In the single SP-TSM approach, three service providers are illustrated: a transportation service provider 32d, an entertainment service provider 32e, and a commercial service provider 32f; and they all share the resources of a single SP-TSM 26d to communicate through an SEI-TSM 22b. The service providers pass secure communications on a carrier operated by an MNO 20b through a mobile device 12b to a particular security module 14b. In this approach, service providers 32d-32f and the SEI-TSM 22b each compensate the SP-TSM 26d for the service it renders. Service providers 32d-32f do not directly approach or pass communications to the SEI-TSM 22b due to current architecture limitations and the complexity of exchanging keys and other information with the SEI-TSM 22b. 
In the multiple service provider trusted service manager approach 10b, every service provider owns or otherwise controls a dedicated TSM. Currently, it is generally recognized that some very large service providers prefer this approach because even though it is expensive (e.g., bringing an SP-TSM 26a-26c online may cost $1 million or more), the large service provider can distinguish itself from its much smaller competitors who cannot afford or justify the investment. For example, even though there are more than 2000 chartered banks in the United States, only a very few of the largest banks have built and control a dedicated SP-TSM 26a. 
In the single service provider trusted service manager approach 10c, a single, centralized TSM negotiates relationships between individual service providers 26d-26f and an issuer of the security modules (SEI-TSM). The negotiation facilitates cooperative technical arrangements such that software applications and security protocols (e.g., key rotation, diversity, and the like) of the service provider cooperate with corresponding applications and protocols of the security module. In these cases, a plurality of service providers may all contribute or otherwise invest in a consortium to create and maintain the central SP-TSM.
All of the subject matter discussed in the Background section is not necessarily prior art and should not be assumed to be prior art merely as a result of its discussion in the Background section. Along these lines, any recognition of problems in the prior art discussed in the Background section or associated with such subject matter should not be treated as prior art unless expressly stated to be prior art. Instead, the discussion of any subject matter in the Background section should be treated as part of the inventor's approach to the particular problem, which in and of itself may also be inventive.